Multimedia data reproducing apparatus, audio data receiving method and audio data structure therein

ABSTRACT

Provided are a multimedia data decoding apparatus, a method of receiving audio data using an HTTP protocol and an audio data structure used for the apparatus and method. The multimedia data reproducing apparatus comprises a decoder receiving AV data, decoding the AV data, and reproducing the AV data in synchronization with predetermined markup data related to the AV data; and a markup resource decoder receiving location information of video data being reproduced by the decoder, calculating a reproducing location of the markup data related to the video, and transmitting the reproducing location of the markup data to the decoder. Audio data is received using the HTTP protocol, not a complex audio/video streaming protocol, and is output in synchronization with video data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of PCT International PatentApplication No. PCT/KR2004/001073, filed May 10, 2004, and Korean PatentApplication No. 2003-29623, filed May 10, 2003, in the KoreanIntellectual Property Office, the disclosures of which are incorporatedherein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Aspects of the present invention relate to audio data transmission, andmore particularly, to a multimedia data reproducing apparatus, a methodof receiving audio data using a hyper text transport protocol (HTTP) andan audio data structure used for the apparatus and method.

2. Description of the Related Art

FIG. 1 illustrates a process of requesting an audio file from a serverand receiving the requested file by a terminal receiving data over theInternet.

Referring to FIG. 1, web browser software, such as Internet Explorer, isinstalled on a terminal 110 receiving data over the Internet. Theterminal 110 can request web data stored on a server 120 to betransmitted using a predetermined protocol via the web browser software.

When the terminal 110 requests an audio.ac3 file, which is a kind ofcompressed audio file, the terminal 110 transmits a file request message130 to the server 120. The server 120 transmits a response message 140to the terminal 110 and then transmits audio data to the terminal 110.Here, a generally used protocol is an HTTP protocol. The received audiodata is temporarily stored in a buffer memory included in the terminal110, decoded by a decoder reproducing data, and output as analog audio.

In detail, markup resource data includes HTML files, image files, scriptfiles, audio files, and video files. The terminal 110, which receivesthe markup resource data, is connected to a web server, on which themarkup resource data is stored, using the HTTP protocol. For example, ifa user wants the terminal 110 to access a site ‘www.company.com’ anddownload an audio.ac3 file, the terminal 110 executes the browser andaccesses the server 120 by typing in ‘http://www.company.com’ in aUniform Resource Location (URL) field. After accessing the server 120,the file request message 130 is transmitted to the server 120. Theserver 120 transmits the response message 140 to the terminal 110.

The server provides the stored markup resource data. Since the terminal110 requests the audio.ac3 file, the server 120 transmits the audio.ac3file to the terminal 110. The terminal 110 stores the received audio.ac3file in the buffer memory. The decoder included in the terminal 110decodes the audio.ac3 file stored in the buffer memory and outputs thedecoded file as analog audio.

In a conventional method of transmitting markup resource data, theterminal 110 requests a complete file and the server 120 transmits thecomplete file, or when a large file, such as audio data, is transmitted,the terminal 110 requests the file by defining in advance a range to betransmitted and the server 120 transmits a portion of the filecorresponding to the range.

However, when data is encoded temporally, and when data to betransmitted is defined according to a time at which the data is to betransmitted, as in audio data, it is difficult to use the conventionalmethod. For example, if various kinds of audio files, such as MP3, MP2,and AC3, exist, when the same time information of the audio files istransmitted to the server 120, and when audio data corresponding to thetime information is requested, it is difficult to use the conventionalmethod since locations of files corresponding to the time informationare different for each kind of audio file.

SUMMARY OF THE INVENTION

An aspect of the present invention provides a method of receiving audiodata using an HTTP protocol, not a complex audio/video streamingprotocol, a structure of received audio meta data, and a structure ofaudio data.

Another aspect of the present invention also provides a multimedia datareproducing apparatus capable of reproducing audio data insynchronization with audio data and video stored in a DVD.

As described above, according to embodiments of the present invention,audio data is received using an HTTP protocol, not a complex audio/videostreaming protocol, and output in synchronization with video data.

For example, a DVD includes movie contents and video in which a directorexplains producing procedures of the movie (director's cut). Thedirector's explanation is commonly produced in one language.Accordingly, a film producing company must produce a special DVD toprovide content in another language, e.g., Korean content. Therefore,since only audio produced with various languages is downloaded over theInternet and output in synchronization with original DVD video, problemsof producing a special DVD can be overcome.

Additional aspects and/or advantages of the invention will be set forthin part in the description which follows and, in part, will be obviousfrom the description, or may be learned by practice of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

These and/or other aspects and advantages of the invention will becomeapparent and more readily appreciated from the following description ofthe embodiments, taken in conjunction with the accompanying drawings ofwhich:

FIG. 1 illustrates a conventional process of requesting an audio filefrom a server and receiving the requested file by a terminal receivingdata over the Internet;

FIG. 2 is a block diagram of a terminal;

FIG. 3 is a block diagram of a server;

FIG. 4 illustrates a process by which a terminal receives audio datafrom a server using meta data;

FIG. 5 is a table showing request messages and response messages used tocommunicate between a terminal and a server;

FIG. 6 illustrates a configuration of an audio.ac3 file;

FIG. 7 is a block diagram of a terminal including a ring type buffer;

FIGS. 8A and 8B are detailed diagrams of chunk headers according toembodiments of the present invention;

FIG. 9 illustrates a process of reading chunk audio data stored in abuffer, decoding the chunk audio data, synchronizing the decoded chunkaudio data with video data, and outputting the synchronized audio andvideo data; and

FIG. 10 is a flowchart illustrating a method of calculating an initialposition of audio data according to an embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Reference will now be made in detail to the present embodiments of thepresent invention, examples of which are illustrated in the accompanyingdrawings, wherein like reference numerals refer to the like elementsthroughout. The embodiments are described below in order to explain thepresent invention by referring to the figures.

According to an aspect of the present invention, there is provided amultimedia data reproducing apparatus comprising: a decoder receiving AVdata, decoding the AV data, and reproducing the AV data insynchronization with predetermined markup data related to the AV data;and a markup resource decoder receiving location information of videodata being reproduced by the decoder, calculating a reproducing locationof the markup data related to the video, and transmitting thereproducing location of the markup data to the decoder.

According to another aspect of the present invention, there is provideda method of receiving audio data, the method comprising: receiving metadata including attribute information of audio data from a server;calculating initial position information of the audio data, transmissionof which is requested, according to the attribute information includedin the meta data; and transmitting the calculated initial positioninformation to the server and receiving the audio data corresponding tothe initial position.

According to another aspect of the present invention, there is provideda method of calculating a location of audio data, the method comprising:converting initial time information of data, transmission of which isrequested, into the number of frames included in the audio data;converting the number of frames into initial position information of achunk, which is a transmission unit of the audio data; and calculatingbyte position information corresponding to the initial chunk positioninformation.

According to another aspect of the present invention, there is provideda recording medium having recorded thereon audio meta data comprising:information regarding a compression format of audio data; informationregarding a number of bytes allocated to a single frame included in theaudio data; time information allocated to the single frame; informationregarding a size of chunk data, which is a transmission unit of theaudio data, and information regarding a size of a chunk header; andlocation information regarding a server in which the audio data isstored.

According to another aspect of the present invention, there is provideda recording medium having recorded thereon an audio data structurecomprising: a chunk header field including synchronization informationdetermining a reference point in time for reproducing the audio data;and an audio data field in which frames forming the audio data arestored.

According to another aspect of the present invention, there is provideda computer readable medium having recorded thereon a computer readableprogram for performing a method of receiving audio data comprisingreceiving meta data including attribute information of audio data from aserver; calculating an initial position information of the audio data,transmission of which is requested, according to the attributeinformation included in the meta data; and transmitting the calculatedinitial position information to the server and receiving the audio datacorresponding to the initial position.

According to another aspect of the invention, there is provided acomputer readable medium having recorded thereon a computer readableprogram for performing a method of calculating a location of audio data,comprising: converting initial time information of data, transmission ofwhich is requested, into a number of frames included in the audio data;converting the number of frames into initial position information of achunk which is a transmission unit of the audio data; and calculatingbyte position information corresponding to the initial chunkinformation.

The chunk header field may include at least one of a pack header fieldand a system header field, which are defined in an MPEG-2 standard. Thechunk header field may include a TS packet header field, which isdefined in the MPEG-2 standard. The chunk header field may also includea PES header field, which is defined in the MPEG-2 standard.

Hereinafter, the present invention will now be described more fully withreference to the accompanying drawings, in which exemplary embodimentsof the invention are shown.

An example of a file request message used when a terminal requests acomplete audio.ac3 file from a server is:

GET/audio.ac3 HTTP/1.0

Date: Fri, 20 Sep. 1996 08:20:58 GMT

Connection: Keep-Alive

User-Agent: ENAV 1.0(Manufacturer).

An example of a response message that the server transmits to theterminal in response to the file request message is:

HTTP/1.0 200

Date: Fri, 20 Sep. 1996 08:20:58 GMT

Server: ENAV 1.0(NCSA/1.5.2)

Last-modified: Fri, 20 Sep. 1996 08:17:58 GMT

Content-type: text/xml

Content-length: 655360.

An example of file request message used when the terminal requests acertain range of the audio.ac3 file from the server is:

GET/audio.ac3HTTP/1.0

Date: Fri, 20 Sep. 1996 08:20:58 GMT

Connection: Keep-Alive

User-Agent: ENAV 1.0(Manufacturer)

Range: 65536-131072.

If the terminal requests data from a 65536 byte position to a 131072byte position of the audio.ac3 file as shown above, an example of aresponse message from the server is:

HTTP/1.0 200

Date: Fri, 20 Sep. 1996 08:20:58 GMT

Server: ENAV 1.0(NCSA/1.5.2)

Last-modified: Fri, 20 Sep. 1996 08:17:58 GMT

Content-type: text/xml

Content-length: 65536.

FIG. 2 is a block diagram of a terminal. Referring to FIG. 2, a terminal200 includes an MPEG data buffer 201, a markup resource buffer 202, anMPEG decoder 203, and a markup resource decoder 204. The terminal 200can receive data from a server 210 via a network or from a recordingmedium 205 such as a disc.

A markup resource stored in the server 210 is transmitted to the markupresource buffer 202, and decoded by the markup resource decoder 204.Video data stored in the recording medium 205 is transmitted to the MPEGdata buffer 201 and decoded by the MPEG decoder 203. The decoded videoand markup resource are displayed together.

FIG. 3 is a block diagram including a server 300. The server 300includes a data transmitter 301, an audio sync signal insertion unit302, and a markup resource storage unit 303. The data transmitter 301transmits data to and receives data from a plurality of terminals, e.g.,310, 320, and 330. The audio sync signal insertion unit 302 inserts async signal for simultaneously reproducing audio and video bysynchronizing the audio and video when the video is reproduced. Themarkup resource storage unit 303 stores markup resource data such as anaudio.ac3 file.

FIG. 4 illustrates a process by which a terminal receives audio datafrom a server using meta data. A terminal 410 transmits a requestmessage requesting meta data (audio.acp) to a server 420 in operation401. The server 420 transmits a response message to the terminal 410 inresponse to the request message in operation 402. Then, the server 420transmits the meta data to the terminal 410 in operation 403.

An example of the audio meta data audio.acp file is: <media version =‘1.0’ > <data name = ‘format’ value = ‘audio/ac3’ /> <data name =‘byteperframe’ value = ‘120’ /> <data name = ‘msperframe’ value = ‘32’/> <data name = ‘chunktype’ value = ‘1’ /> <data name = ‘chunksize’value = ‘8192’ /> <data name = ‘chunkheader’ value = ‘21’ /> <data name= ‘location’ value = ‘http://www.company.com/ac3/audio.ac3’ /> </media>.

As indicated above, the audio meta data includes an audio file format, anumber of bytes per frame, a time for reproducing a single frame, achunk type, a size of a chunk, a size of a chunk header, and a locationof stored audio data. The terminal 410 stores the received audio metadata audio.acp file in a buffer memory included in the terminal 410.Here, the audio.acp meta data can be read from a disc or received from aserver via a network. The audio.acp meta data can also be transmitted asany type including a file type.

The terminal 410 receives the audio.acp meta data and calculates alocation of audio data to be read in operation 404. A method ofcalculating the location of the audio data will be described below. Whenthe location is calculated, the terminal 410 transmits a messagerequesting the actual audio file audio.ac3 to the server 420 inoperation 405. The server transmits a response message to the terminal410 in response to the audio file request message in operation 406 andthen transmits audio.ac3 audio data to the terminal in operation 407.

FIG. 5 is a table showing request messages and response messages used tocommunicate between a terminal and a server. Referring to FIG. 5,messages transmitted from a terminal to a server include a meta datarequest message and an ac3 file request message, and messagestransmitted from the server to the terminal include response messages inresponse to the request messages.

FIG. 6 illustrates the configuration of an audio.ac3 file. The audio.ac3file shown in FIG. 6 includes chunk header fields 610 and 630 and ac3audio data fields 620 and 640. The chunk header fields 610 and 630include synchronization information determining a temporal referencepoint for reproducing audio. The ac3 audio data fields 620 and 640include audio data including a plurality of frames. A single audio framecan be included in a single ac3 audio data field, and the single audioframe, such as a fourth frame 624, can be divided into two portions.

A process of calculating a location of audio data that a terminalrequests from a server is as follows. The terminal calculates the numberof bytes corresponding to an initial position requested by the terminalby analyzing audio meta data audio.acp stored in a buffer memoryincluded in the terminal. For example, if an initial position of a filerequested by the terminal is 10 minutes 25 seconds 30 milliseconds, theterminal converts the initial position into a unit of milliseconds inadvance. In this case, 10:25:30=625,030 milliseconds. The calculatedvalue is converted into a number of frames using the reproducing timeper frame (ms/frame) used in the audio meta data.

The number of frames is calculated as 625,030/32=19,532, andaccordingly, an audio data frame following the 19,532th frame is theinitial position. Also, a chunk to which the 19,533th frame belongs iscalculated. That is, the size of 19,532 frames is calculated as19,532*(the number of bytes allocated to a frame)=19,532*120=2,343,840bytes.

The size of data included in the ac3 audio data field 620, not includingthe chunk header field 610, is (the size of chunk−the size of the chunkheader)=8,192−21=8,171. In the above example, dividing the size of totalframes by the size of data, 2,343,840/8,171, yields 286 chunks.Therefore, audio data starting from a 287th chunk is received. Here, alocation of the 287th chunk converted into a unit of bytes is 286*(thesize of chunk), a 2,342,912th byte position.

The terminal transmits the following message including byte positioninformation calculated as described above to the server to receive audiodata:

GET/audio.ac3 HTTP/1.0

Date: Fri, 20 Sep. 1996 08:20:58 GMT

Connection: Keep-Alive

User-Agent: ENAV 1.0(Manufacturer)

Range: 2342912-2351103.

The server transmits an audio data file audio.ac3 to the terminal. Here,the ac3 file can be read from a disc or received from the server via anetwork.

FIG. 7 is a block diagram of a terminal including a ring type buffer.Referring to FIG. 7, a terminal 700 stores a received markup resourcedata audio.ac3 file in a markup resource buffer 702 included in theterminal 700. The markup resource buffer 702 is a ring type buffer andconsecutively receives and stores data in multiple chunk units. A markupresource decoder 704 decodes the audio.ac3 file stored in the ring typemarkup resource buffer 702 and outputs the decoded audio.ac3 file.

DVD AV data stored in a recording medium 705, such as a disc, istransmitted to a DVD AV data buffer 701, and a DVD AV decoder 703decodes the DVD AV data. Finally, the DVD AV data decoded by the DVD AVdecoder 703 and the audio.ac3 file decoded by the markup resourcedecoder 704 are reproduced simultaneously. The DVD AV data may also beprovided from a server 710 via a network.

FIGS. 8A and 8B are detailed diagrams of chunk headers according toembodiments of the present invention. A chunk header according to anembodiment of the present invention can be defined to follow theISO/IEC-13818 Part 1 and a DVD standard such that a DVD file may beeasily decoded. As shown in FIG. 8A, in a program stream (PS), the chunkheader includes a pack header 810, a system header 820, and a packetizedelementary stream (PES) header 830, which are written in ISO/IEC-13818.Also, only one of the pack header 810 and the system header 820 may beincluded in the chunk header. As shown in FIG. 8B, in a transport stream(TS), the chunk header includes a TS packet header 840 and a PES header850.

A presentation time stamp (PTS) of chunk data is included in the PESheaders 830 and 850. If a fragmented frame exists at an initial positionof an audio data field, the PTS indicates an initial position of a fillframe.

FIG. 9 illustrates a process of reading chunk audio data stored in abuffer, decoding the chunk audio data, synchronizing the decoded chunkaudio data with video data, and outputting the synchronized audio andvideo data.

Synchronization between chunk audio and DVD video is performed asfollows. The markup resource decoder 704 confirms a reproducing timeposition of current DVD video. If it is assumed that the reproducingtime position is 10 minutes 25 seconds 30 milliseconds as above, alocation of relevant chunk audio can be easily determined. A method ofreproducing audio using an ECMAScript will now be described usingapplication programming interfaces (APIs).

[obj].elapsed_Time is API transporting reproducing time positioninformation of the DVD video.

Regardless of whether synchronization with the DVD video is required andwhether synchronization with the reproducing time position informationof the DVD video is required when the chunk audio is synchronized andreproduced, the API: [obj].playAudioStream(‘http://www.company.com/audio.acp’, ‘10:25:30’, true), designatingwhere the chunk audio is located is required.

The above API indicates that a designated audio meta file, such as‘http://www.company.com/audio.asp’, has been downloaded and decoded, andwhen the DVD video is being reproduced for 10 minutes 25 seconds 30milliseconds until a relevant point in time, reproduction of the chunkaudio starts by synchronizing an audio frame obtained by a PTScalculation of a chunk audio stream corresponding to the time.

However, the API below is used when an audio clip is reproduced when theaudio clip is reproduced as an infinite loop without synchronization orwhen the audio clip is reproduced only once:

[obj].playAudioClip(‘http://www.company.com/audio.acp’, -1).

The API is used for downloading and decoding a designated audio metafile from ‘http://www.company.com/audio.acp’, downloading a relevantaudio clip to the markup resource buffer 702, and reproducing the audioclip using the infinite loop.

Here, instead of forming a file including the audio meta data, the audiometa data may be calculated using a program language (for example,Javascript, Java language) or a tag language (for example, SMIL, XML),to directly extract information related to frames, and reproduce theaudio clip.

Embodiments of the present invention may be applied to not only audiodata but also multimedia data configured with a fixed bitrate, forexample, media data such as video, text and animation graphic data. Thatis, if the video, text and animation graphic data have a chunk dataconfiguration, it is possible to reproduce the video, text and animationgraphic data in synchronization with the DVD video.

FIG. 10 is a flowchart illustrating a method of calculating an initialposition of audio data according to an embodiment of the presentinvention. Reproduction initial time information of an audio file isconverted into the number of frames forming audio data in operationS1010. The number of frames is converted into an initial position of achunk in operation S1020. Byte position information corresponding to theinitial position of the chunk is calculated in operation S1030. The byteposition information is transmitted to a server in operation S1040, andthe audio data, starting from the desired position, is received from theserver.

The invention may also be embodied as computer readable codes on acomputer readable recording medium. The computer readable recordingmedium is any data storage device that can store data which can bethereafter read by a computer system. Examples of the computer readablerecording medium include read-only memory (ROM), random-access memory(RAM), CD-ROMs, magnetic tapes, floppy disks, optical data storagedevices, and carrier waves (such as data transmission through theInternet). The computer readable recording medium may be distributedover network coupled computer systems so that the computer readable codeis stored and executed in a distributed fashion.

Although a few embodiments of the present invention have been shown anddescribed, it would be appreciated by those skilled in the art thatchanges may be made in this embodiment without departing from theprinciples and spirit of the invention, the scope of which is defined inthe claims and their equivalents.

1. A multimedia data reproducing apparatus comprising: a decoderreceiving AV data, decoding the AV data, and reproducing the AV data insynchronization with predetermined markup data related to the AV data;and a markup resource decoder receiving location information of videodata being reproduced by the decoder, calculating a reproducing locationof the markup data related to the video data, and transmitting thereproducing location of the markup data to the decoder.
 2. The apparatusof claim 1, further comprising a markup resource buffer receiving andstoring the markup data.
 3. The apparatus of claim 2, wherein the markupresource buffer is a ring type buffer and stores markup resource datarelated to the AV data in predetermined chunks.
 4. The apparatus ofclaim 3, wherein each chunk comprises: a chunk header field includingsynchronization information determining a reference point in time forreproducing audio; and an audio data field in which audio frames arestored.
 5. The apparatus of claim 1, wherein the markup data is audiodata.
 6. A method of receiving audio data, the method comprising:receiving meta data including attribute information of the audio datafrom a server; calculating initial position information of the audiodata, transmission of which is requested, according to the attributeinformation included in the meta data; and transmitting the calculatedinitial position information to the server and receiving the audio datacorresponding to the initial position.
 7. The method of claim 6, whereinthe meta data comprises: information regarding a compression format ofthe audio data; information regarding the number of bytes allocated to asingle frame included in the audio data; time information allocated tothe single frame; information regarding a size of chunk data, which is atransmission unit of the audio data, and information of a size of achunk header; and location information regarding the server in which theaudio data is stored.
 8. The method of claim 6, wherein the calculatingof the initial position information comprises: receiving timeinformation indicating an initial position of the audio data,transmission of which is requested; converting the time information intoinformation indicating a number of frames forming the audio data;converting the information indicating the number of frames into initialposition information of a chunk forming the audio data; and calculatingbyte information corresponding to the initial position information ofthe chunk.
 9. A method of calculating a location of audio data, themethod comprising: converting initial time information of data,transmission of which is requested, into a number of frames included inthe audio data; converting the number of frames into initial positioninformation of a chunk which is a transmission unit of the audio data;and calculating byte position information corresponding to the initialchunk position information.
 10. The method of claim 9, wherein eachchunk comprises: a chunk header field including synchronizationinformation determining a reference point in time for reproducing audio;and an audio data field in which frames forming the audio data arestored.
 11. A recording medium having recorded thereon audio meta datacomprising: information regarding a compression format of audio data;information regarding a number of bytes allocated to a single frameincluded in the audio data; time information allocated to the singleframe; information regarding a size of chunk data, which is atransmission unit of the audio data, and information of a size of achunk header; and location information regarding a server in which theaudio data is stored.
 12. A recording medium having recorded thereon anaudio data structure comprising: a chunk header field includingsynchronization information determining a reference point in time forreproducing the audio data; and an audio data field in which framesforming the audio data are stored.
 13. The method of claim 12, whereinthe chunk header field includes at least one of a pack header field anda system header field, which are defined in an MPEG-2 standard.
 14. Themethod of claim 12, wherein the chunk header field includes a TS packetheader field, which is defined in an MPEG-2 standard.
 15. The method ofclaim 12, wherein the chunk header field includes a PES header field,which is defined in an MPEG-2 standard.
 16. A computer readable mediumhaving recorded thereon a computer readable program for performing amethod of receiving audio data comprising: receiving meta data includingattribute information of the audio data from a server; calculating aninitial position information of the audio data, transmission of which isrequested, according to the attribute information included in the metadata; and transmitting the calculated initial position information tothe server and receiving the audio data corresponding to the initialposition information.
 17. A computer readable medium having recordedthereon a computer readable program for performing a method ofcalculating a location of audio data comprising: converting initial timeinformation of data, transmission of which is requested, into a numberof frames included in the audio data; converting the number of framesinto initial position information of a chunk which is a transmissionunit of the audio data; and calculating byte position informationcorresponding to the initial chunk information.
 18. A method ofreproducing multimedia data, comprising: receiving AV data, decoding theAV data, and reproducing the AV data in synchronization withpredetermined markup data related to the AV data; and receiving locationinformation of video data being reproduced, calculating a reproducinglocation of the markup data related to the video data, and transmittingthe reproducing location of the markup data to a decoder.
 19. The methodof claim 18, further comprising: receiving the AV data via a networkusing an HTTP protocol: receiving the predetermined markup data from astorage medium not connected to the network.
 20. The method of claim 19,wherein the AV data corresponds to audio data in a different languagefrom corresponding audio data recorded on the storage medium.
 21. Themethod of claim 20, wherein the markup data comprises a video portion ofdata reproduced from a DVD.
 22. The method of claim 19, wherein thenetwork is the Internet.
 23. The method of claim 18, further comprising:receiving the AV data via a network using an HTTP protocol: receivingthe predetermined markup data from a storage medium connected to thenetwork.
 24. The method of claim 23, wherein the AV data corresponds toaudio data in a different language from corresponding audio dataavailable from the storage medium connected to the network.
 25. Themethod of claim 24, wherein the markup data comprises a video portion ofdata reproduced from a DVD.
 26. The method of claim 22, wherein thenetwork is the Internet.
 27. The method of claim 18, further comprising:receiving the AV data from a first source using an HTTP protocol; andreceiving the predetermined markup data from a second source using otherthan the HTTP protocol.
 28. The method of claim 27, wherein the AV datacorresponds to audio data in a different language from correspondingaudio data available from the source having the markup data.
 29. Themethod of claim 28, wherein the markup data comprises a video portion ofdata reproduced from a DVD.
 30. The method of claim 27, wherein thefirst source is a network and the second source is a DVD.
 31. The methodof claim 6, further comprising: transmitting the audio data from theserver in one of a plurality of chunks; and reproducing the audio datain synchronization with video data reproduced from a DVD based on thecalculated initial position information for a respective chunk.